Design a Qdrant-backed search feature for a SaaS product with thousands of small customers, each with their own private dataset. What collection and sharding strategy would you use?

For thousands of small customers, the right design is a shared collection with a tenant_id discriminator payload field, custom sharding by tenant, and a payload index on tenant_id marked with is_tenant=True. Each tenant's data is identified by the tenant_id field, and every query includes a filter on that field. Custom sharding co-locates each tenant's data on a single shard, so a tenant-scoped query hits one shard instead of fanning out to all shards. This is the combination that balances isolation with operational simplicity: the data is logically isolated by the filter, the query is efficient because it is routed to a single shard, and the operational overhead is one collection and a small number of shards rather than one collection per tenant. The official Qdrant guidance explicitly recommends this pattern over one-collection-per-tenant because per-tenant collections do not scale past a few hundred and waste resources on the fixed overhead of each collection.

The mechanism that makes custom sharding work is that the shard key is chosen by the application, not hashed from the point ID. When you create a shard key for a tenant and upsert points with that shard key, Qdrant places all of those points on the shard associated with that key. A query that specifies the shard key is routed to that shard only, so the query does not fan out. This is the key to scaling to thousands of tenants: without custom sharding, every query would fan out to all shards, and the coordinator's merge cost would grow with the number of shards. With custom sharding, the query cost is bounded by the shard's size, not by the total number of tenants. The tenant_id field is also marked with is_tenant=True, which tells the optimizer that this field is used for tenant scoping and enables optimizations in the index and query planning. The combination of custom sharding (for routing) and is_tenant (for indexing) is the recommended multi-tenant pattern for current Qdrant versions.

The trade-off is between isolation and operational simplicity. A shared collection with filters provides logical isolation, which is sufficient for most SaaS products but not for tenants with strict physical-isolation requirements. Custom sharding improves query efficiency but requires the application to manage shard keys and to handle the case where a tenant grows large enough to warrant its own shard. The common mistake is to create one collection per tenant, which does not scale. The second mistake is to not use custom sharding, so every query fans out to all shards. The third mistake is to rely on the tenant filter alone without a payload index, which forces a scan on every query. The fourth mistake is to let clients query Qdrant directly, which means they could omit the tenant filter and see other tenants' data - the filter must be enforced by a trusted service. The fifth mistake is to not plan for a tenant that grows much larger than the others, which creates a hot shard. Version note: custom sharding and the is_tenant flag were added in recent Qdrant releases. If you are on an older version, the multi-tenant pattern may not have the same optimizations, and the practical threshold for the number of tenants in a shared collection may be lower.

Version-dependent: custom sharding (sharding_method=models.ShardingMethod.CUSTOM) and the is_tenant flag were added in recent Qdrant releases and have evolved. The exact API for creating shard keys, the supported key types (keyword vs integer), and the behavior when a shard key is not specified have changed. If you are on an older version, verify the multi-tenant support and benchmark the tenant-scoped query latency with your actual tenant distribution.